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1 Introduction to the Document 


1.1 Purpose of the Document 

• The SRDH State Adoption Strategy document is a value proposition document for 
SRDH, developed for the soon-to-be or future SRDH owners, which provides adoption 
strategies for successful deployment of SRDH 

• This document primarily aims to provide the States with enabling levers to adopt SRDH 

• The document is essentially recommendatory in nature, though there could be areas, 
where security of UID and KYR data is paramount, that it may attempt to mandate 

• The document does not provide technical installation procedures and issue resolution 
methods 

1.2 Target Audience 

The intended audience for this document is: 

• Appointed SRDH State Nodal Officers and/or UID Registrars 

• IT Secretaries of States 

• Departmental Heads of States 

• State’s IT department team/selected SI vendor 
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2 Introduction to SRDH Application Framework 

2.1 Objectives of SRDH 

The SRDH aims to: 

• Manage complete State level Resident Data in a Digitized, Centralized and Secure 
manner 

• Enhance Aadhaar Data Security 

• Leverage Resident Data in Service Delivery Applications 

• Easily incorporate Aadhaar authentication into various applications 

A detailed overview of functions of SRDH has been provided in the Section 4: Appendix of this 
document. It is highly recommended that readers of this document go through that information 
on SRDH. 


2.2 Summary on SRDH 

The overall context and scope of the SRDH initiative is described below: 

• The State Resident Data Hub (SRDH) Application Framework is expected to enable the 
states to build a clean master database of state-specific residents whose details shall be 
derived from the Aadhaar enrolment data. This should provide the platform to allow 
States to: (1) build a master database of clean, authentic and up-to-date resident details 
using the KYR data as gathering during the Aadhaar enrolment process, and (2) weed 
out duplicate and fake resident records that could be existing in various state 
governmental databases and systems, and potentially silo-d setup. 

• The deployment of the SRDH Application Framework in the state data centers would 
create an infrastructure for states to manage their own data, starting with the Aadhaar 
enrolment data as the base. The various departments in the State and UT are expected 
to access this data store via well-defined API/s and then perform resident-data- 
enrichment as needed. 

• The SRDH Application Framework would also allow for secure wrapper services for 
accessing the resident information via clearly defined RBAC (Role Based Access 
Control). These wrapper services shall also enable search and update of resident 
records by exact / partial match. 

• The SRDH Application Framework would provide a basic view of the resident (typically 
KYR information as captured during the Aadhaar enrolment); and also allow for the 
State-specific department databases to connect and access the same. 

• The SRDH Application Framework would provide seeding utilities that allow users to 
map existing KYR equivalent data in departments to clean KYR records as in SRDH in 
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an interactive semi-automated manner to enable the seeding of Aadhaar numbers into 
State-specific department databases. 

• The SRDH Application Framework would readily support Aadhaar Authentication using 
Authentication API such that States may adopt Aadhaar Authentication into their 
applications with minimalistic configuration changes. 

• Provide reporting capabilities in terms of metrics that provide a snapshot of the health 
and performance of SRDH. 

• The SRDH application framework provides for a basic query builder that allows technical 
users to query remote departmental databases, persist the resulting data temporarily in 
SRDH and then allow users to cross-query across SRDH and the persisted 
departmental data. This allows users to plan for welfare schemes since beneficiary 
entitlement criteria are typically spread across multiple departments currently. 

• Lastly, the SRDH Application Framework would also be able to push EID-UID files and 
packets (both Biometric and KYR+) onto the ‘UIDAI Vault’; thus making the data less 
prone to theft and abuse. 

Conceptual flow of data is as shown below: 
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Land Records 
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SRDH Applicationframework 
accessible by means of wrapper 
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A more detailed process flow is depicted below: 


© 2012 All rights reserved. 


Page 11 of 33 











AADHAAR 


UIDAI - SRDH - State Adoption Strategy Document 


SRDH Framework Process Diagram 
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2.3 Benefits of SRDH 

Deploying SRDH provides a State with: 

• Valid demographic data that is CIDR verified 

• Opportunity to use this: 

o demographic data (containing Aadhaar numbers) for Seeding various State 
application databases with Aadhaar number 
o demographic data and clean up its own applications’ databases 

• Legitimate Resident data accessible to States’ applications - the much sought after 
Aadhaar integration becomes a reality 

• Out-of-the-box AUA Server Software to expedite implementation of Aadhaar 
authentication for State applications 

• Ability to better manage the fund disbursement and social welfare / financial inclusion 
schemes 

Operational guidelines and related details on how to take up SRDH deployments and be able to 
reap the above listed benefits have been provided in the following sections. 
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3 SRDH Application Framework’s State Adoption Strategy 


The SRDH Application Framework’s State Adoption Strategy provides Indian States with a 
holistic view and operational guidelines on how to deploy, manage and operationalize SRDH. 

The following subsections would primarily talk about: 

• On the ground practices and roadmap to prepare for, deploy and manage SRDH 

• Procedure to become an AUA 

• Typical SRDH usage scenarios to leverage SRDH benefits 

o Seeding 
o AUA services 

o KYR and/or SRDH Data updation 
o Business case scenarios 

• Resident data acquisition approaches 

• KYR and UID/demographic data sharing procedure 

• Deployment Risks 

• SRDH Application Framework customizations 

• Change Request Management 

• Warranty and Support 

• Local language support inbuilt with SRDH 

• SRDH relevant infrastructure and personnel readiness 

• Governance and ownership of SRDH 

• SRDH Product training and sensitization workshops 

• Collaboration with other State departments 
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3.1 SRDH Data Availability 

3.1.1 Enrolment Data 

The UIDAI / Aadhaar Enrolment Data come from various sources and in different forms. It is 
important to understand these as that will give adequate insight on data management in SRDH. 


Nature of Data 

Packets 

KYR+ Database Files 

EID-UID XML Files 

Demographic 
Information (KYR) 

S 



Biometrics 

(Fingerprints and Iris) 


X 

X 

Photograph 

S 

X 

(Most Registrars have not 
captured photo in KYR+) 

(Possible to include 
photograph) 

EID 

S 


S 

UID 

X 

X 

V 

KYR+ Information 

X 

✓ 

X 

Secure (Password / 
Encryption) 


X 

s 


3.1.2 Why only KYR 

UIDAI is providing SRDH Application Framework to States, which uses various methods to 
collate and maintain KYR data of State residents into a single database. Three such methods 
are: 

1. EID-UID mapping files, provided to registrars who enroll residents, and who update 
resident data 

2. Organic (Manual) data Addition / Update by SRDH business users. This is only done 
after authentication of data against CIDR data. 

3. Organic (Manual) data Addition / Update by State residents also known as Resident Self 
Service. This is only done after authentication of data against CIDR data. 

By default, all data which may be included in SRDH trough one of the methods above is KYR 
data, as defined in Aadhaar enrollments. KYR+ data fields (Program Identifiers) such as Ration 
Card Number, MGNREGS Job Card Number, and Driving License Number etc. have not been 
included consciously in SRDH. The reason is that various departments which manage 
program/scheme data may simply seed their beneficiary/resident data with Aadhaar number, 
which enables a logical linking. If SRDH were to also maintain all Program identifiers also, it will 
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be duplication of data, which results in problems of synchronization and obsolete data. Ensuring 
a single-source-of-truth on resident data helps in better management of the data. 

However, States may take a decision to add more fields in SRDH, if they strongly feel the need 
to do so. The same may be achieved by State’s IT team or System Integrator. 

Finally, SRDH is intended to provide access to KYR data to State departments. Authentication 
should be carried out against the CIDR database of UIDAI using the authentication framework 
introduced later in this document. Hence SRDH does not need to (and should not) store 
biometric data. 

3.1.3 Data Sources 

Sufficient KYR data is the cornerstone of SRDH functions. A State must have access to KYR 
data of its Residents for a successful launch of SRDH. 

SRDH Data basically comprises of KYR data along with EID/ UID numbers and citizen 
photograph. The relevant rows from the enrolment data tables as in previous section are: 


Nature of Data 

Packets 

KYR+ Database Files 

EID-UID XML Files 

Demographic 
Information (KYR) 

y 

y 

y 

UID 

X 

X 

y 


The KYR data collected during Enrolments as in Packets does not yet have the UID numbers. 
Once the UID numbers are generated they are published by UIDAI on the Portal (accessible 
only to Registrars) in the form of EID-UID XML files. These XML files will very soon be 
encrypted and also carry the photograph. SRDH is designed to support both unencrypted and 
encrypted EID-UID XML files with or without photographs. 

Note that the earliest generation of EID-UID XML files published by UIDAI carried only EID and 
UID numbers and did not have any KYR data, these files are not usable in SRDH since KYR 
data is the core of SRDH. 


3.1.4 Data Availability and Exchange 

The EID-UID files published by UIDAI are available to registrars through the registrar portal. 
Currently, UIDAI is constrained by the existing data policy to only publish KRY records of those 
enrolled by the particular registrar in the EID-UID file sent to the registrar. This constraint leads 
to various issues: 
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- Citizen KYR records are hence distributed across various registrars. These registrars could be 
State or non-State registrars and for a minority of cases would also be registrars who are 
operating in a different State. 

- Any given EID-UID file could contain KYR records of individuals who is a citizen of a different 
State. 

- Collation attempts of KYR data for a State would hence require transfer of EID-UID files across 
registrars and hence security of data needs to be considered. 

The State should bear in mind the above complications and put in place mechanisms to collate 
resident KYR data in SRDH. Multiple strategies would need to be in place such as below: 

Seeking Data from Registrars: 

• UIDAI Data Sharing Policy: Currently, as per the UIDAI Data Sharing Policy, Aadhaar 
(KYR) data collected during Enrolments are published on the UIDAI Portal and allows a 
Registrar to access ONLY its own KYR data - hence, a State Registrar cannot access 
data enrolled by Non State Registrars. 

UIDAI is currently reviewing this Data Sharing Policy and considering necessary 
update(s) so that KYR data of all State residents can be made available to the State 
Registrar. While any such Policy change becomes effective, the State should plan 
alternative strategies. 

• Memorandum of Understanding (MoU): One such alternative strategy could be for a 
State to have a MoU signed with the Non-State Registrars that would allow the Non 
State Registrars to share with State Registrar all their KYR data captured during the 
enrolments. 

• Informal Agreements / Understanding: State should try and discuss to form informal 
agreements that could help them obtain the Non State Registrar Data. 

Seeking Data from Residents 

Data can be sought from Residents in the following ways: 

• Resident Self Service 

o SRDH Resident Self-Service Portal - (inbuilt in SRDH Application Framework 
being provided by UIDAI). This would allow direct Update by the Resident in 
SRDH after CIDR Authentication. State could consider exposing this functionality 
of the SRDH application through State Portals. 

• Resident - Assisted 

o SRDH application users either from nodal agency or approved departmental 
users with appropriate access can capture KYR data from residents and insert/ 


© 2012 All rights reserved. 


Page 17 of 33 


AADHAAR 


UIDAI - SRDH - State Adoption Strategy Document 


update the same into the SRDH database through the organic (manual) insert 
functionality currently available in the SRDH application which appropriately first 
authenticates data with CIDR automatically. This could be done at: 

o Touch-points (Point of Service - POS) Residents may walk-in with latest 
Aadhaar Data / Letter to Citizen Service Centers (CSC) networks or other points 
of service. 

o Data Update request by Physical Post. The resident may post a copy of their 
Aadhaar Letter to the Nodal Department managing SRDH. The Application user 
may use the data to make the update. 

o Specific Data Collection Camps: The SRDH nodal agency could conduct 
specific data collection camps or work with departments who might conduct 
camps specifically for their scheme where KYR data can be collected from 
residents and inserted/ updated in SRDH through the organic insert/ update 
functionalities. 


State vs. Non State Residents Data 

As earlier discussed in this sub section, UIDAI follows a multi-registrar approach for 
enrollments, which results in State enrolling Residents who belong to other States, as well as 
other Registrars, including Banks and other States, enrolling Residents of a particular State. 

SRDH Nodal Department in a State may want to maintain data of only its Residents in the State 
SRDH instance. The SRDH Application Framework provided by UIDAI has an option to 
selectively keep data of ‘State Residents’ only. There’s a configurable “Switch” in SRDH which 
allows the SRDH user to load KYR data for only State Residents from EID-UID files which 
contain residents of multiple states. Alternatively, the SRDH user may choose to load all of the 
KYR data provided and then selectively fetch, through the “Search” feature to find all Non State 
Residents and “Deactivate” their records. 

For a Resident’s background, the following definition holds: 

• State Resident - Any resident whose Aadhaar data has the corresponding State name 
in the ‘State’ field of address. 

• Non-State Resident - Any resident whose Aadhaar data has any other State name in 
the ‘State’ field of address 

Secure Transfer of Data between State and Non State Registrars using a Secure Utility 

A State is strongly advised to have adequate Security mechanisms for data exchange, to avoid 
compromise of sensitive Resident information. In view of this, it is recommended a State 
obtaining EID-UID files from multiple registrars or sending EID-UID files to other entities always 
do so with appropriate encryption. 
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3.2 SRDH Data Integrity 

SRDH dataset for a State is conceptualized as a subset of CIDR data. It is critical that all efforts 
be taken to ensure that data in SRDH is in sync with CIDR which in turn will provide the 
necessary assurance of data integrity. In that context, SRDH has built in functionality to auto- 
authenticate data with CIDR at all points of insert/ update such as from EID-UID files, organic 
insert/ update and Resident Self Service insert/ update functionalities. 

The AUA-ASA (Authentication User Agency-Authentication Service Agency) framework 
designed by UIDAI to help implement Aadhaar authentication is to be leveraged by SRDH. In 
that context, it is highly recommended that the nodal agency at the State for SRDH also operate 
as the AUA for the State and could either be an ASA or leverage any existing ASA. 

Currently many States have a large number of unencrypted EID-UID files and the Aadhaar 
authentication framework is not yet setup at the State. Keeping this in mind, SRDH can be 
configured during deployment to ‘switch off” authentication for data inserted/ updated from EID- 
UID files. This would allow States to expedite loading SRDH with KYR data at the known risk of 
loading data that might not have been sourced from CIDR. This can however be handled by the 
State at a later date once the authentication framework is in place by leveraging the 
‘authenticate existing records’ functionality of SRDH. 

It is highly recommended that organic insert/ update as well as resident self service not be used 
without authentication framework first being implemented in the State. This would ensure that 
any manual entry whether by residents or SRDH business users is always first authenticated 
with CIDR as the probability of error in manually entered data will be very high. 


3.2.1 AUA Services 

SRDH will function as an AUA and will route all authentication requests from registered 
departmental applications to CIDR and back. While the Nodal Department for SRDH in a State 
could be an AUA, the other departments which would route their Authentication Requests 
through the SRDH AUA server could be Sub-AUA’s. A classic case of such a deployment is 
demonstrated below where the IT Department in the State is the Nodal Department for SRDH 
(and also the AUA), and other departments such as Food & Civil Supplies, Social Welfare, Rural 
Development and Education are routing their authentication requests. 
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KYR Data Authentication Requests Sent and Responses Received through SRDH 


Department of Social 
Welfare 


Rural Department 


Department of 
Education 


Department of Food 
& Civil Supplies 


Different State Department Applications Send KYR Data Authentication Requests 


Note that SRDH application also leverages the AUA services for organic insert/ update, resident 
self service and EID-UID file insert functionalities. 

Since the UIDAI authentication framework is out of the scope of SRDH and is an independent 
initiative, it is highly recommended that the State familiarize themselves with the same as 
available at www.uidai.qov.in/auth . Minimal relevant details of the authentication framework are 
provided in the Appendix. 

3.2.2 Keeping Data Up to Date 

Most of the basic KYR information of a Resident does not change over time. However, data like 
Last Name, Address, Phone No. etc. often undergo change due to marriage, movement to other 
towns/cities etc. 

Any change to KYR data needs to be first done at Cl DR. This is currently enabled through 
various proposed channels as part of the Cl DR updation strategy project. 

It is important that SRDH data is maintained up-to-date so that actual benefits for the State 
Nodal Department and all Departments which would use the services of SRDH be reliable. 
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Any change in KYR data at CIDR is published by UIDAI as an ‘UPDATION’ record in EID-UID 
XML files. This file however is published only to the registrar to whom the resident provided the 
updated details. This registrar could be a non-state registrar or even a registrar operating in 
another State. Hence the same issues and strategies as already detailed in section on ‘Data 
Availability and Exchange’ previously in this document would apply. 

3.2.3 Key Messages to Residents 

Residents have an important role to play. The States should communicate the following 
approach to residents so that residents are enabled to participate in keeping their data up-to- 
date in SRDH. The messages may be communicated to residents through Newspaper 
advertisements, TV/Radio jingles, etc. 

• Update data in CIDR: Whenever, there is a change in resident data, such as Name 
Change, Address Change or Mobile Number Change, residents must always use one of 
the Update channels opened by UIDAI to update their data in CIDR. The two most 
common channels for doing so are the permanent Update/Enrollment Centers and the 
Self-Service Update Portals of UIDAI. Details would be available on the UIDAI website 
(www.uidai.qov.in ) in due course of time, when UIDAI rolls out Update services. 

• Update data in SRDH: SRDH would have a resident portal for addition of data and 
update of data. Once the resident’s data in updated in CIDR, the residents should be 
encouraged to update their data in SRDH as well. This data may be updated by the 
residents directly through any of the other channels opened up by the State. 

3.3 Usage of SRDH 

The key usage of State resident KYR data in SRDH is by the various State departments for 
‘Seeding’ and Cleaning’ of departmental databases. 


3.3.1 ‘Seeding’ or ‘Aadhaar Seeding’ 

Seeding is the process of linking (inserting) Aadhaar number in a program/scheme/department 
database. For example - seeding of Aadhaar number in Ration Card database is maintained by 
Food & Civil Supplies department of the State. 

It is critical that department/ scheme databases are seeded with Aadhaar numbers in order to 
identify individual beneficiaries which in turn sets up readiness for Aadhaar enabled service 
delivery, both Aadhaar Enabled Payment Services (AEPS) as well as Aadhaar Authentication. 
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The SRDH application has in built seeding utilities to enable the same. Manual seeding feature 
of SRDH can be used wherein the mapping between department/ scheme beneficiary ID (such 
as job card number in MNREGA or Ration Card Numbetr in PDS) and UID (Aadhaar number) is 
known or can be discovered by the SRDH user through search functionalities of SRDH 
application. This functionality allows the departmental user to download the SRDH KYR data for 
these beneficiaries in CSV format. 

Batch seeding feature of SRDH is a semi-automated version of the manual seeding feature 
which reduces the tediousness of having to do manual searches. SRDH users can upload a 
CSV (of a pre-determined format/ template) containing departmental data (KYR equivalent data 
currently in Department). The SRDH application processes the input CSV (searches for input 
records against SRDH database) and provides an interactive feature which allows the SRDH 
user to map the input beneficiary record against UID numbers in SRDH. After the inetarctive 
mapping process is completed, the user can download the SRDH KYR data for the mapped 
beneficiaries in CSV format. 

In both the above cases, the downloaded information can now be used by the department for 
seeding their own databases. The same information can also be used for cleaning the KYR data 
currently in department as explained in below section. 

It is also possible that Departmental software applications can leverage the web services 
exposed by SRDH to seed their databases. 

3.3.2 Data Cleaning 

KYR data currently available with departments are typically prone to multiple data quality issues. 
For example, ‘Name’ of a beneficiary across various departments/ schemes are spelt differently 
and often does not match the actual beneficiary name. The same issues of data quality are 
more pronounced in address data. 

The adoption of Aadhaar enabled payments and Aadhaar authentication by various State 
departments for service delivery requires that KYR data in the departments match those with 
UIDAI. The process of updating departmental KYR data to that of UIDAI KYR data is termed 
‘Cleaning’ in this section. 

Data Cleaning is imperative to successful implementation of Aadhaar enabled service delivery. 
The process of Data Cleaning allows a State to ensure that KYR information is correct and 
usable for various Resident services and Social and Financial Inclusion programs. 

While cleaning Departmental data using SRDH (through APIs or CSV files from SRDH Batch 
Seeding) a Department may wish to retain pre-existing Departmental KYR data in addition to 
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the SRDH KYR data. For example, a Departmental database may contain two fields - for 
example one is say “Name” and the other being “Name_Aadhaar”. 

Over the long term, one of the intentions of SRDH is to have KYR data in a standardized and 
consistent form across all Departments. Over a period of time, Departments would move to 
relying on SRDH KYR data (ex: “Name_Aadhaaar) within their databases and stop using older 
Departmental KYR data (ex: “Name”). This would ensure consistent and standard KYR data 
across Departmental databases. 

3.3.3 Starting up with clean KYR data 

SRDH KYR data can be accessed through web services. This can be leveraged by any State 
application where beneficiaries are applying for a service such as say applying for a Job Card 
though any MNREGA application or through a State Portal or through a CSC application. In any 
case, KYR data for a given Aadhaar number can be fetched from SRDH into the application 
form through web services thus ensuring clean KYR data right at the creation of a beneficiary 
record in a department/ scheme database. 


3.3.4 Access Control 

Access to SRDH KYR data needs to be controlled to ensure security and address privacy 
considerations (sharing policy). In that context, SRDH application usage creates audit records 
withing the SRDH application database instance. The nodal agency should periodically review 
audit trails to ensure appropriate usage of the application. Further any other application 
accessing SRDH through web services needs to be audited to ensure that necessary audit 
details are captured as well as any data transfer is both legitimate and secure (encrypted 
transfers). 

Further, SRDH currently only allows read access through web services. The SRDH application 
has an access control module which the application administrator can leverage to provide 
individual users with permissions for each separate functionality of the SRDH application. It is 
important that the SRDH administrator ensures that only legitimate approved users can get write 
access to SRDH data. Finally the SRDH application can be configured to ensure that any KYR 
data insert or update will first be authenticated against Cl DR as explained previously in the 
‘Data Integrity’ section. This configurability needs to be setup by the nodal agency thus ensuring 
data integrity. 

In order to ensure that Departmental access to KYR data is secure, the State needs to have in 
place the following: 
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• Departmental Data Sharing Policy 

There has to be a Data Sharing Policy defined for SRDH so that only the relevant or the 
required data is shared. This can be enforced through the access control module of the 
SRDH application. 

• Data Security 

Any transfer of SRDH data to a Department through the usage of Web Services over a 
network must only happen in a secure encrypted form. 

3.4 Operating SRDH at State 

Operating SRDH at the State requires 

• Governance structure for ownership and accountability with details of various 
stakeholder roles and responsibilities 

• Hardware, Software and Manpower requirements based on scale and performance 
needs 

• Managing SRDH application in terms of 

a. Intellectual Property Rights (IPR) 

b. Customization Guidelines including recommended on application environments 
and version control 

c. Local language support 

• Deployment and Configuration guidelines and recommendations 

• Capacity building in terms of sensitization, training and change management 

• Mechanisms to leverage best practices across States and from among departments 
within a State 

• Security and data sharing guidelines to ensure data integrity and privacy considerations. 

All these above topics are detailed as part of the “Institutional Framework Recommendations for 
SRDH at States” document. 
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4 Appendix 


4.1 Functions of SRDH 


Function Name 

Description 

Login 

The login function will be used to authenticate a user before the user 
can start using the system. This will also determine the functions within 
the system which the user will be able to access, based on the user 
configuration. Note that although the SRDH system provides a self 
contained user management module, it can however be configured to 
use an existing LDAP service which is often available in the State 
environments where the system is expected to be deployed 

User Management 

The user management function is used when the SRDH administrator 
or super user wishes to add a new user to the system or modify the 
details of an existing user or delete a user account. Note that although 
the SRDH system provides a self contained user management module, 
it can however be configured to use an existing LDAP service which is 
often available in the State environments where the system is expected 
to be deployed. 

Insertion of EID 

UID file 

Batch insert of data into SRDH using one or more encrypted or 
unencrypted EID-UID file as input. All encrypted files are expected to be 
encrypted with the State registrar public key. State registrar private key 
is required to decrypt encrypted input files to unencrypted EID UID XML 
files. Further processing after decryption is the similar for both kinds of 
files except that records emanating from unencrypted EID-UID files can 
optionally be authenticated against Cl DR before insertion/ updation into 
SRDH. Records emanating from encrypted EID-UID files will not be 
authenticated against CIDR before insertion/ updation into SRDH. For 
records that already exist in SRDH, this feature would modify the data if 
the input data is newer than existing data 

Insertion of a 
record manually 

Insert of a single record into the SRDH using data manually entered, 
wherein the record is first authenticated with the CIDR before insertion 
into the SRDH. For records that already exist in SRDH, modify record 
functionality should be used 
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Function Name 

Description 

Modification of 

records 

Modification of a record already present in the SRDH using data 
manually entered, wherein the record is first authenticated with the 
CIDR before modification of the same in SRDH data store. 

Resident Self 

Service of 
insert/modify KYR 
manually 

Insert/ modify of a single record into the SRDH using data manually 
entered by a resident through a self service screen of SRDH, wherein 
the record is first authenticated with the CIDR before insertion/ 
modification into the SRDH. Resident will need to register with SRDH 
and will get an OTP (temporary One Time Password) by mobile or eMail 
or both and the self service would be possible only for a configurable 
limited time period after which resident will have to request for OTP 
again. Once a self service transaction has been completed successfully, 
resident will not have access to self service unless he requests for OTP 
again. 

De-activate 

records 

This function will be used to make a record inactive. A user with the 
deactivate authorization will search for a particular record or a set of 
records (The result would be a standard single record view or a 
standard multiple record view matching the search criteria) and then 
deactivate them. Each record being deactivated will have a “reason”. 
The “reason” can be any one of multiple pre-fixed reasons as 
configured by administrator with one chosen as default. When using 
batch deactivate, “reason” is defaulted. This will be updated in the 
SRDH database. User will be asked to reconfirm the deactivation 

Authenticate 
existing records 
with the CIDR 

This function will be used to authenticate an existing record in the 
SRDH with the central CIDR. A user with CIDR authentication access 
will search for a record to be verified (The result would be a standard 
single record view or a standard multiple record view matching the 
search criteria). The system will then connect to the central CIDR to 
verify the record selected by the user and generate a report that will 
show the results of the verification 
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Function Name 

Description 

Simple search 

This will be a simple search which will enable a user to search SRDH 
records. The search can be based on any of the KYR data elements 
such as UID number, EID number, name, address, DOB, Mobile 
number, email address, relative name, relative EID/UID etc. The UID 
number will be the default search criteria. The result would be a record 
or a set of records matching the search criteria. Search will restrict user 
to start with a minimum of 3 characters. The result would be a standard 
single record view or a standard multiple record view matching the 
search criteria 

Advanced search 

This will enable a user to search SRDH records based on multiple KYR 
fields using the AND logic or to search for records that have been 
inserted/deleted/modified between two different dates or a combination 

of both. Search will restrict user to start with a minimum of 3 characters 
for each free-text search criteria. The result would be a standard single 
record view or a standard multiple record view matching the search 
criteria. 

Seeding utility 

This functionality will allow department (such as PDS, MNREGA etc) 
users to enter UID numbers and map to their department specific citizen 
ID such as job card number for MNREGA or Ration Card Number for 
PDS etc as already setup in the "seeding utility configuration". The 
functionality can be operated in single or batch mode. 

In single mode, user manually does the seeding using search to find the 
resident record and then mapping to department specific resident ID. 

In batch mode, user uploads a CSV containing data from the 
department pertaining to resident KYR which is then processed against 
KYR as in SRDH. 

In either mode, the output can then be downloaded as a CSV file which 
will have columns: (a) UID Number, (b) Department specific Citizen ID 
and (c) Y/N for record availability in SRDH (d) KYR data fields as in 
SRDH. This will provide the necessary pre-formatted input to enable the 
state application databases to be seeded with the Aadhaar number. 

UIDAI Vault - 
Upload 

This functionality will allow a user to connect to the data vault and 
upload files (expected to be registrar packets or KYR+ database files or 
EID-UID XML files) to be stored for later use. Once a file is uploaded 
the meta-data will be stored in the SRDH system 
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Function Name 

Description 

UIDAI Vault - 

Download 

This functionality will also allow users to download previously stored 
files from the vault. When the user connects to the data vault, all the 
files that have been uploaded by the user will be visible. The user will 
place a download request to the vault. The vault will respond to the 
request as per the vault SLA timelines. 

Registration of an 
external database 

This is an admin functionality to enable the SRDH query builder. This 
allows the SRDH administrator to register a remote database with the 
SRDH system and make it available for the query builder functionality. 
Note that the external database must already have been seeded 
(should have UID numbers) 

SRDH Query 

Builder 

The SRDH query builder will be used to formulate database queries and 
run them against remote departmental databases for any given ’Where’ 
condition. 

Authenticate 
remote requests 

SRDH will function as an AUA and will route all authentication requests 
from registered departmental applications (Sub-AUAs) to CIDR and 
back. For AUA server requirement mainly SRDH has to implement 
Authentication API. Rest of the things are mainly regarding 
infrastructure which states need to take care. 

API for reading 
SRDH 

SRDH will provide an API interface for known registered applications to 
use for reading SRDH data. All functionalities of SRDH should be 
available through this API. It is recommended that the SRDH application 
itself internally use the same API for its browser based Ul. Default 
configuration should deploy SRDH with only search and advanced 
search functionalities exposed for other applications to leverage. 
However it should be possible to expose other functionalities through 
configuration. Also, API should provide clean and parameterized 
interface for all functionalities: for example, CIDR authentication for 
SRDH core functionalities like manual record insertion requires exact 
match authentication but the relevant function exposed by the API 
should take as input the match settings which the core application 
functionality uses with ‘exact match’ parameter inputs 
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Function Name 

Description 



Standardized 

Reports 

Standardized reports would be the factual information (quantified 
results) that a SRDH application portal user would want to see on a 
daily basis (when he/she logs in). Necessary queries need to be built for 
reporting on 15 metrics 
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4.2 Nodal Agency as an AUA 

4.2.1 Introduction 

AUA is any government / public / private legal agency registered in India that seeks to use 
Aadhaar authentication for its services. An AUA is the principal agency that sends 
authentication requests to enable its services / business functions. 

An AUA connects to the Cl DR through an ASA (either by becoming ASA on its own or 
contracting services of an existing ASA). 

Examples of AUAs: 

• Department of Civil Supplies, which seeks to verify the identity of a target resident before 
issuing them their monthly ration of rice, kerosene, etc. 

• Any bank / financial institution that seeks to verify the identity of its customer before 
letting them complete a financial transaction such as withdrawal or transfer of funds. 

• The administration/security department of a high-security building/zone that seeks to 
verify the identity of any individual seeking entry into the building/zone. 

4.2.2 AUA Readiness Stages 

• Identify business / service delivery needs: The agency needs to identify service 
delivery areas where Aadhaar authentication may be used. The agency also needs to 
decide what authentication types they would be using for Aadhaar enabling different 
service delivery needs. 

• Fill online application form: Any agency interested in becoming an AUA needs to 
apply online. UIDAI has an online workflow based application form for engaging with 
AUAs. 

• Engage with ASA(s): One of the initial stages for becoming an AUA is the need to 
engage with an existing ASA. The list of approved ASAs would be available online and 
an interested AUA can engage accordingly. In case an agency wants to become both 
ASA and AUA, it would first need to get approved as an ASA and then apply for 
becoming AUA. 

• Send signed contract and supporting documents to UIDAI: The AUA should send 
hardcopy of the signed contract along with required supporting documents to UIDAI. The 
online application would be approved by UIDAI upon receipt of the required documents. 

• Ensure process and technology compliance: The AUA needs to setup necessary 
systems, processes, infrastructure etc. in compliance with UIDAI’s standards and 
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specifications. Some such requirements include defining exception handling mechanism, 
developing application using Aadhaar authentication APIs, ensuring connectivity from 
authentication devices to the AUA server etc. Compliance to various requirements needs 
to be confirmed to UIDAI through the online application form. 

• Plan device deployment: The AUA needs to decide upon the authentication device 
specifications based on its business requirements and ensure deployment of same. If an 
AUA opts for biometric authentication, the sensor/extractor of the devices needs to be 
certified by STQC. If an AUA opts for operator-assisted devices, the AUA would also 
need to ensure training and readiness of operators. 

• Obtain approvals from UIDAI: UIDAI would approve an AUA’s application form when 
various compliance requirements are met. An AUA should engage with UIDAI during the 
process and provide required clarifications. 

• Carry out end-to-end testing: Approval from UIDAI allows an AUA to carry out end-to- 
end testing of their application with the Cl DR. Before going live with actual resident 
authentication, it is highly recommended that an AUA carries out thorough end-to-end 
testing of their application with the selected ASA and with CIDR. The AUA should get the 
systems related to Aadhaar authentication audited by information systems auditors 
certified by a recognized body before going live. 

• Go-live: An AUA can go-live after confirmation of adherence to all UIDAI’s standards 
and specifications. UIDAI plans to manage the same through online workflow based 
application. 


4.2.3 Key AUA Responsibilities 

• Choose an appropriate authentication type based on business and deployment risk 
assessment; inform UIDAI regarding the same. 

• Ensure compliance of authentication related operations (processes, technology, security, 
etc.) to UIDAI’s standards and specifications. 

• Prepare authentication packet as per Authentication API specifications. 

• Log and maintain details of all authentication transactions. 

• In case Aadhaar biometric authentication is used, ensure Best Finger Detection (BFD) 
application is implemented to on-board the residents for biometric authentication. 

• Identifying exception-handling and back-up identity authentication mechanisms. 

• Deploy fraud monitoring mechanism, as per AUA’s business needs, to prevent misuse of 
exception handling mechanism by operators and any other ecosystem members. 

• Get its operations and systems related to Aadhaar Authentication audited as per UIDAI’s 
specifications. 

• Ensure connectivity from authentication devices to the AUA server and between the 
AUA server and the ASA server. 

• Procure, deploy and manage devices in compliance with UIDAI specifications. 

• Ensure adequate training for the personnel managing authentication devices. 
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• Inform UIDAI of the engagement/ disengagement of Sub AUAs. 

• Ensure supported Sub AUAs comply with UIDAI’s standards and specifications. 

• Inform UIDAI of any misuse of Aadhaar data, authentication services, or any 
compromise of Aadhaar related data or systems. 

4.2.4 Mandatory Security Requirements 

• Aadhaar number should be never used as a domain specific identifier. 

• In the case of operator assisted devices, operators should be authenticated using 
mechanisms such as password, Aadhaar authentication, etc. 

• PID block captured for Aadhaar authentication should be encrypted during capture and 
should never be sent in the clear over a network. 

• The encrypted PID block should not be stored unless it is for buffered authentication for 
a short period, currently configured as 24 hours. 

• Biometric and OTP data captured for the purposes of Aadhaar authentication should not 
be stored on any permanent storage or database. 

• The meta-data and the responses should be logged for audit purposes. 

• Network between AUA and ASA should be secure. 

More details on Authentication and AUA are available on www.uidai.qov.in/auth . 


** END OF DOCUMENT ** 
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